Skip to content

MDEV-39813 ST_GeomFromGeoJSON does not control recursion depth - #5469

Open
grooverdan wants to merge 3 commits into
MariaDB:10.6from
grooverdan:MDEV-39276_2
Open

MDEV-39813 ST_GeomFromGeoJSON does not control recursion depth#5469
grooverdan wants to merge 3 commits into
MariaDB:10.6from
grooverdan:MDEV-39276_2

Conversation

@grooverdan

@grooverdan grooverdan commented Jul 29, 2026

Copy link
Copy Markdown
Member

Resolve geojson parser to using the json_engine_t to preserve killability and depth control.

A minor difference resulted in on ordering issue with type: at the end of the json becoming an incorrect result.

ported MDEV-39989 from #5243 to preserve and fix results for all types since it was really simple.

grooverdan and others added 2 commits July 29, 2026 14:44
Geometry::create_from_json used strings as things that reinitialize
the je (json_engine). By reinitializing with json_start the killed
pointer gets reset, and also the concept of depth is reset.

There are two states in create_from_json:
1. The search if for the type, once found ci is set
2. Search for the argument, arg becomes != T_NONE

If the type is found first, ci become the class, and once
the arg is found, continued execution on the same je occurs.

If the argument comes before the "type", we've save a copy
of the json_engine_t to process this argument.

In both cases je after the execution is the most progressed
pointer.

Debug assertions on je state aren't enforced by code, if
some invalid GeoJSON is passed, these are actual errors.

Because Geometry::create_from_json is recursive, from
geometrymcollections, a json_read_value is pushed from inside this
function up to Item_func_geometry_from_json::val_str.

Other Gis*::init_from_json start from their actual object and don't
need a json_read_value to start.

Test case an bug report thanks to byteoverride.
…d key order

ST_GEOMFROMGEOJSON requires JSON keys to appear in a specific order
(type before geometries/features/geometry/coordinates). When keys
appear in a different order, the JSON scanner is left in an
inconsistent state because json_skip_level() is not called to advance
past the value when the type has not yet been determined.

Fix: add json_skip_level() calls in the geometries, features, and
geometry key handlers when the type key has not yet been encountered.
This mirrors the existing pattern in the coordinates handler.

All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license. I am contributing on behalf of my employer Amazon Web
Services, Inc.

@sanja-byelkin sanja-byelkin left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why it is not a rebase?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

4 participants